歡迎光臨本餐廳，我是您今晚的服務生 小笠宏樹，今晚您想吃 Java牛還是烤Python呢？

今晚我想來點有趣的
Ylvis - Trucker's Hitch 

嗨嗨～今天要來講的是作者本人的切身經歷

狀況一

某一次在大公司裡面，上面來了個要求是要把關所有的軟體產品的品質，並且之後要交一份報告上去說怎麼提高軟體品質的，然後各個產品目前做到什麼樣的情況，因此可怕的一次大清掃就來了，由於當時我們這邊負責的產品是整體大小偏大的邏輯篇複雜的產品，因此我們立刻被盯上了，瘋狂的被要求要縮小產品的大小還有提升長官試到的產品操作上的速度，那時真是痛不欲生的地獄，最後還導致我們砍了一些功能才達成要求，那個時候同事間最常抱怨的就是「憑什麼要不同的產品要有一樣的標準啊！」

結論一

就跟當我們在看公司財報時我們不可以只專注在財報一樣，很多時候不同的產業別就會有其特點和特性，不可能要求物流業的毛利跟服務業一樣高，也不可能要求台積電的資產降的跟小型工廠一樣多，這些都是不合理的。而這些假如用在軟體上就會產生上面的可怕狀況。
要改善這件事情對於財報這方面也有很多種方式可以來做觀察

• 業種業態比
  • 找到性質雷同的產品來做比較，雖然在資料的可比性上會需要多注意一下，比方說同樣都是通訊軟體，但有一個可以下載貼圖，一個不行，這樣比較起來也還是不能完全類比，但至少比起原本的方式我們更近了一步。
• 時間軸比
  • 通常對於財報來說都是年比還有季比，不過重點不是時間的區間，而是要去知道這個期間內軟體新增了什麼樣的功能，然後整體的數值如何改變。

狀況二

上司很常會利用軟體的財報數值來評價軟體的品質，這裡先給個前提是就算是前述的問題早就已經解決，因此數值比較的基準是有道理的情況下，這個評價還是有它的風險，隨便舉個例子好了，當軟體的大小比較小、執行速度比較快就一定代表程式碼的命名規則、可讀性、架構一定是好的嗎？再給個例子，很多時候我們在寫程式上其實會為了可讀性讓程式碼寫得更多一點，執行的速度慢一點，那這個行為一定是錯的？

結論二

必須理解財報終究只是公司的片面事實擷取下來，並且由於這些片面事實的計算方式，也會導致其會有某些的偏見，就跟投資股票時一樣，財報只是判斷的標準之一。

上面舉了兩種常見的財報的錯誤地閱讀的方式，其實主要目的也是希望我們在看待數值的時候是用正確的概念和方式去理解它，而不是盲目的就相信數字，財報我們都常聽到作假了，何況是軟體測量出來的數據呢～也是有各式各樣作假的空間。

最後再多講個東西，雖然我不是QA的專業，但也有看過QA為了產生時間性的比較資料，因此會每隔一段時間就將軟體產品自動化的跑過一輪測試，並自動化的產生一些基礎報表，就像是企業定期產出財報一樣。

以上就是「財報不正確的閱讀方式」的內容
明天來講講流水線生產